1. Field of the Invention
The present invention relates to an IPv6 mobile node that can move to an IPv4-only access network and still retain its reachability to another IPv6 node located in a different address space.
2. Description of Related Art
The following abbreviations are herewith defined, at least some of which are referred to in the ensuing description of the prior art and the preferred embodiments of the present invention.    MN Mobile Node is a mobile terminal which can communicate with other moving or stationary nodes using its home address while it is changing its attachment point to the Internet (IP network).    HA Home Agent is a router in the MN's home network.    CN Correspondent Node is an IPv6 node. The MN is also a CN but CN could also be a node which doesn't move at all.    NAT Network Address Translator.    CoA Care-of Address is an IPv6 or IPv4 address which is used by the MN in the visiting network. This address changes as the MN changes its attachment to the Internet. When the MN is attached to an IPv4 access network it also needs a UDP port number together with its IPv4 CoA. This is because the IPv4 tunnelling could be going through one or more NATs and they need the UDP port to perform the address translation.    HoA Home Address of the MN is the IPv6 or IPv4 address it is always reachable from. If the MN is not in a home link the HA will tunnel the packets to the MN which arrive to the HoA of the MN.    HL Home link.    HoTI Home Test Init.    HoT Home Test.    CoTI Care-of Test Init.    CoT Care-of Test.    BU Binding Update.    BA Binding Acknowledgement.
In the wireless communications field, a protocol known as Mobile IPv6 is used today which allows IPv6 MNs to remain reachable while moving around in IPv6 access networks connected to an IP network like the Internet. Without this mobility support, packets destined to an IPv6 MN would not be able to reach it while it is located away from its home link. The Mobile IPv6 protocol is described in detail in the following documents:                S. Deering et al., “Internet Protocol, Version 6 (IPv6) Specification”, RFC 2460, December 1998.        D. Johnson et al., “Mobility Support in IPv6”, RFC 3775, June 2004.The contents of these documents are incorporated by reference herein.        
In addition to the IPv6 access networks, there are also IPv4 access networks in use today that are connected to the Internet. The IPv4 access networks are designed and made in accordance with another protocol known as Mobile IPv4. The Mobile IPv4 protocol enables an IPv4 MN to be reached while it is located in an IPv4 access network that is not its HL. The Mobile IPv4 protocol is described in detail in the following document:                C. Perkins, “IP Mobility Support”, RFC 2002, October 1996.The contents of this document are incorporated by reference herein.        
Unfortunately, the Mobile IPv4 and Mobile IPv6 protocols are designed for IPv4-only access networks and IPv6-only access networks, respectively. As such, the Mobile IPv6 protocol does not provide backwards compatibility to IPv4 networks. This means that Mobile IPv6 is not capable of mobility management across IPv4 (public and private) access networks. However, mobility management of IPv6 MNs located in IPv4 (public and private) access networks is particularly important. Because, IPv6 MNs (e.g., IPv6 mobile computers) are likely to account for a majority or at least a substantial fraction of the population of the devices that are going to be connected to the Internet. And, some of the access networks to the Internet will be IPv4-only access networks. A proposed solution to this mobility management problem is described in detail below with respect to FIGS. 1 and 2.
Referring to FIGS. 1A and 1B (PRIOR ART), there is shown a diagram and a signaling flow diagram used to help explain a solution to the mobility management problem in a scenario where an IPv6 MN 110 moves to an IPv4-only access network 116 and can still retain its reachability to an IPv6 CN 102. As shown in FIG. 1A, the IPv6 CN 102 is located in a mixed IPv4/IPv6 access network 104 which has an IPv4 router 106 and an IPv6 router 108. And, the MN 110 moved from a HL 112 which has a HA 114 to an IPv4 access network 116 which has an IPv4 router 118. The MN 110 is able to communicate with the CN 102 via the Internet 120 as discussed next.
As shown in FIGS. 1A and 1B, the MN 110 performs a home registration with the HA 114 after it moves from the HL 112 to the IPv4 access network 116 (see signals 1 and 2). To perform the home registration, the MN 110 sends a BU to the HA 114 (signal 1). Since, the MN 110 is located in the IPv4 access network 116 it adds an IPv4 Care-of address option to the BU to learn its global IPv4 address and UDP port. Then, the HA 114 sends the MN 110 a BA which carries the IPv4 Care-of address option holding the MN's global IPv4 address and UDP port (signal 2). After the home registration, the CN 102 sends traffic (tunneled data) to the MN 110 via the HL 112 (see signal 3). The MN 110 also sends traffic (tunneled data) to the CN 102 via the HL 112 (see signal 4). In addition, the MN 110 has a routing table 122. An exemplary routing table 122 is provided below:
MN's Routing Table 122:Destination:Next hop:Intf:“HA IPv6”“HA IPv4”UDP tunnelintf0“HA IPv4”“default IPV4 router”Intf0
A drawback of this solution is that the incoming and outgoing traffic for the MN 110 is always tunneled via the HA 114 which resides in the HL 112. The same traffic route would still be needed even if the CN 102 and the MN 110 were located in the same access network. This is because the CN 102 and MN 110 cannot engage in a route optimization procedure where the traffic is routed via the shortest path (MN 110, IPv4 router 118, Internet 120, IPv4 router 106, CN 102) since the CN 102 and MN 110 may loose connectivity when the MN 110 moves to another access network (not shown in picture). It would be desirable if the MN 110 and CN 102 could engage in a route optimization procedure. This need is addressed by the present invention.
Referring to FIGS. 2A and 2B (PRIOR ART), there is shown a diagram and a signaling flow diagram used to help explain a solution to the mobility management problem in a scenario where an IPv6 MN 202 retains its reachability to another IPv6 MN 212 even when both IPv6 MNs 202 and 212 move to IPv4-only access networks 204 and 214. As shown in FIG. 2A, the first IPv6 MN 202 is located in an IPv4 access network 204 which has an IPv4 router 206. The first MN 202 moved to the IPv4 access network 204 from a HL 208 which has a HA 210. The second IPv6 MN 212 is located in an IPv4 access network 214 which has an IPv4 router 216. The second MN 212 moved to the IPv4 access network 214 from a HL 218 which has a HA 220. And, the first MN 202 is able to communicate with the second MN 212 via the Internet 222 and the HAs 210 and 220 as discussed next.
As shown in FIGS. 2A and 2B, the first MN 202 performs a home registration with the HA 210 after it moves from the HL 208 to the IPv4 access network 204 (see signals 1a and 1b). To perform the home registration, the first MN 202 sends a BU to the HA 210 (signal 1a). Since, the first MN 202 is located in the IPv4 access network 204 it adds an IPv4 Care-of address option to the BU to learn its global IPv4 address and UDP port. Then, the HA 210 sends the MN 202 a BA which carries the IPv4 Care-of address option holding the MN's global IPv4 address and UDP port (signal 2a). Likewise, the second MN 212 sends a BU to the HA 220 (signal 1b). Since, the second MN 212 is located in the IPv4 access network 214 it adds an IPv4 Care-of address option to the BU to learn its global IPv4 address and UDP port. Then, the HA 220 sends the MN 212 a BA which carries the IPv4 Care-of address option holding the MN's global IPv4 address and UDP port (signal 2b). After the home registration, the second MN 212 sends traffic (tunneled data) to the first MN 202 via the two HLs 218 and 208 (see signal 3). The first MN 202 also sends traffic (tunneled data) to the second MN 212 via the two HLs 208 and 218 (see signal 4). In addition, the MN 202 and 212 each have a routing table 224 and 226. Exemplary routing tables 224 and 226 are provided below:
MN1 Routing Table 224:Destination:Next hop:Intf:“HA1 IPv6”“HA1 IPv4”UDP tunnelintf0“HA1 IPv4”“default IPV4 rouler”Intf0
MN2 Routing Table 226:Destination:Next hop:Intf:“HA2 IPv6”“HA2 IPv4”UDP tunnelintf0“HA2 IPv4”“default IPV4 router”Intf0
A drawback of this solution is that the incoming and outgoing traffic between MN 202 and MN 212 needs to be tunneled via two HAs 210 and 220 which reside in the HLs 208 and 218. The same traffic route would still be needed even if both MNs 202 and 212 were located in the same access network. This is because the MNs 202 and 212 can not engage in a route optimization procedure where the traffic is routed via the shortest path (MN 202, IPv4 router 206, Internet 222, IPv4 router 216, MN 212) since the MNs 202 and 212 may loose connectivity when either or both of them move to an IPv4 network 204 and 214. It should be noted that the two MNs can not optimize the routing between them even if they are in IPv6 access networks because one of them might at any time move to an IPv4 access network. It would be desirable if the MNs 202 and 212 could engage in a route optimization procedure. This need is addressed by the present invention.